Many times, software is delivered in “packages”. The process of building these packages starts with a “source” package that contains the actual source code plus information on how that source code should be “compiled” into a binary package form. The binary packages are ones that would be installed on an end user system. A single source package may be built on various systems (of different CPU architectures) so that the resulting binary packages are compatible with the various architectures (e.g., 32-bit Intel, 64-bit Intel, PowerPC, S390, etc). Some organizations perform “native building,” which means that the machine used to build a binary package from a source package (“build machine”) is the same architecture as the machine used to install the binary package (“target machine”). For example, a PowerPC based machine is used to build a binary package for a PowerPC-based target machine, an S390-based machine is used to build a binary package for an S390-based target machine, etc. The build operations typically require a relatively large amount of compute resources (CPU speed, RAM space, disk space, etc), so typically dedicated build machines are set aside at an organization to perform the build process.
However, smaller devices that use CPUs, such as embedded CPUs, are not really suitable for use as build machines. For example, cell phones often use ARM CPUs with no disk space and just a small amount of RAM. Because these devices are special-purpose machines, they typically cannot run the tools and utilities needed to build the binary packages. In order to build packages for such devices, a different and more powerful build machine, such as an Intel-based desktop PC, should be used to create the binary package for these devices. This is referred to as “cross-building.”
Cross-building of software packages is not new. Over the years, various approaches have been provided for cross-building. Typically, these approaches involve a fair amount of manual setup to satisfy build dependencies. That is, each package to be built requires that certain other packages be installed (i.e., dependencies). For instance, a package for a word processor application may require spell check libraries provided by some other package. So, before building the word processor package, the spell check package containing those libraries must be installed. A given source package contains lists of other packages that are required for building that source package.
Generally, a utility that manages the building of software packages will read a list of build prerequisites from a source package and then fetch and install those prerequisites before doing the actual build setup. This works fine for native building but this problem space is more complicated for cross-building and the utility is not able to adequately handle those differences. For cross-building, there are two types of build dependencies: (1) libraries of the architecture for the target machine (not for the build machine), and (2) utilities/tools needed to run on the build machine (not for the target machine architecture). The problem is that the managing utility will assume that all build dependencies are based on the build machine architecture, thereby not providing the correct package dependencies for a cross-building situation.